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Graphic  Presentation  of  Data  Structures  in  the  DBX 

Debugger 


David  B.  Baskerville 

Computer  Science  Division 

Department  of  Electrical  Engineering  and  Computer  Sciences 
University'  of  California  at  Berkeley 
Berkeley.  California  94720 


1.  Overview 

This  paper  describes  the  design  and  implementation  of  an  extension  to  a  standari 
debugger  The  extension  presenu  data  stmctures  graphically  and  enables  a  user  to  control  the 
format  and  extent  of  information  provtd^i.  The  extension  to  the  debugger  DBX  |t^ 

1984!  runs  on  a  Sun  Worksution  under  the  Su^Windows  window  manager  ISun  19831.  The 
system  is  successful  in  presentmg  even  complex  data  structures  in  an  effect.ve  mannm  with 
good  performance,  A  user  may  move  and  modify  data  structures  on  the  screen  and  may- 
control  the  amount  of  information  presented  about  records,  arrays,  or  linked  structures. 

Sections  2  through  5  of  this  paper  discuss  desirable  presentation  features  of  a  debugger 
and  delineate  the  objectives  of  the  graphical  debugger.  Section  6  illustrates  ^e  graphi^ 
presentation  of  data  structures  accomplished  by  the  extended  DBX  Secticin  7  descnbes  ^e 
commands  for  graphic  display.  Section  8  describes  in  some  depth  the  imp  ementatmn  of  tte 
graphic  extension.  The  concluding  sections  relate  performance  results  and  ideas  for  further 

work. 

2.  The  Debugging  Problem 

Data  structures  are  fundamental  to  computer  programs.  A  computer  program  can  often 
be  charactenxed  by  the  data  structures  it  creates  and  the  operations  it  perf-onns  upon  them. 

In  designing  a  program,  or  attempting  to  undersUnd  a  program,  a  visual  representat,^ 
of  the  program  s  data  structures  m  often  essential.  Introdurioo'  programming  courses  t^cd. 
students  to  think  about  dau  stniaures  in  box  form  with  pointers  represented  by  orr^s  from 
one  box  to  another.  Experience  has  proven  this  8ox4.nd4.rrom  form  to  be  a  worthwhile  way  of 
conceptualizing  data  structures.  Advanced  programmers  think  about  data  ktriiriures  u.  the 
same  way,  visualizing  8ox4.nd4.rrou-  mcxiels  of  linked  lists,  binary  trees,  and  symbol  tables. 

In  debugging  a  program,  the  user  has  access  U.  a  potentially  vast  amount  of  information 
about  the  program  and  its  state.  The  debugger  should  he  able  to  organize  and  present  thm 
information  in  a  way  that  is  useful  and  natural  to  the  user.  In  particular,  the  m^  comm,.n 
presentation  task  of  a  debugger  is  to  -.ow  the  value  of  a  variable,  which  may  be  a  mmple 
value  or  a  data  structure.  Therefore,  it  is  uicumbent  on  the  debugger  to  be  capable  of 
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pre«ntm8  »ch  dau  rtmctum  in  tha  sama  form  in  which  ua«3  thmk  of  tham  Un 
atmcturas  Aould  ha  p^aantad  aa  boxas  foinad  by  arn..s  from  <ma  box  u>  anothar, 

should  appear  vmually  aa  naatad  boxaa.  During  intaracfva  J 

atructuraa  ara  praaant»i  aa  uaara  naturally  think  about  tham.  .m.ta  can  ba  s^ttad  mora 
quickly  and  an  underaundmg  of  the  progtam  a  axacution  can  ba  ach.avad  mora  taa  i  y^ 

Traditionally,  dabuggata  have  ptaaantad  information  aa  text,  making  no  attampt  m 
ptaaent  data  atnictuiaa  in  a  bc-a.d -arrow  format.  Attempta  to  do  ao  on  a  low  raaolution  awn. 
Lrminal  would  prove  futile.  Tba  biggaat  drawback  of  taxfbaaad  dabuggara  m  the  way  .n 
which  potnmra  ara  pnisantad.  Tbaae  dabuggara  display  the  value  of  a  pointer  aa  > 
addraaa  of  the  atructur.  pointed  to  ia  given.  Vet  it  ia  the  objwn  pointed  to,  not 
ia  uaually  of  intereat.  Ilia  user  must  follow  polntara,  printing  out  componanta  of  a  1 
atructuta  individually,  to  tacor, struct  the  state  of  a  data  atructura  on  hta  aemteh  paper.  If  a 
«7tual  debugger  were  to  present  all  the  obi«m  .minted  to,  the  dood  of  Uiformation  would 

quickly  scroll  off  the  screen. 

3.  The  Solution 

The  advent  of  high-raaolution  bit-mapped  displays  affords  the  possibility  for  dabuggara  to 
ptaaent  data  atnicturaa  aa  the  user  anvtaiona  them.  Since  the  .mplamanution  U  no  long^ 
limited  to  text,  a  debugger  can  draw  nested  boxaa  and  interconnecting  arrows  u,  raptaaent 
daU  structure,  ameliorating  the  drfjugglng  process. 

Presenting  data  atructurea  in  the  familiar  hoxWuirtom  form  alone,  however,  ia  not 
enough  It  ia  vital  that  the  user  be  allowed  to  control  the  format  and  extent  of  infomauon 
diaplLed  about  a  data  atructura.  A  user  may  conceive  of  binary  tra.  vary  d«v 
linked'  lists,  even  though  the  underlying  data  atructuraa  ara  aasentmlly  the 
should  be  able  to  specify'  how  certain  data  atructuraa  ara  formatted  on  the  screen  ao 
presentation  matches  hia  conception.  He  should  also  ba  able  to  move  the  data  atrocturas  once 
LThava  appeared  on  the  screen.  This  capability  enables  the  user  to  alter  the  way  ha  views  a 
data  atructura  or  to  improve  a  layout  that  becomes  inappropriate  aa  data  structures  change 

dynamically. 

Presenting  all  the  information  held  in  a  complex  daU  atruitura  may  ba  t^  much  demi 
,t  is  important  to  allow  the  user  to  tailor  a  data  structure's  presenutam  m  show  only  tht* 
parts  which  he  would  like  to  focus  upon.  Such  control  can  ba  provided  by  Hie  u^  to 

dose  a  certain  subatruaure,  to  suppress  a  pointer  «.d  its  linked  atructura,  or  to  ebde  parts  of 

an  array. 

4.  Objectives  of  the  Graphical  Debugger 

Hie  UNn  debugger  DBX  is  a  symbolic,  sourte  language  debugger,  supporting  C,  Pa^l. 
Fortran,  and  assembly  language.  Breakpoints  may  be  set  at  wiurca  code  Ima  numbata,  at  to 
beginning  of  procedures,  or  upon  a  condition  which  the  user  specifies  After  a  ' 

axLtion  of  to  program  can  be  continued  in  single  step  mode,  ptocadurea  may  ba  caUad.  etc 
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A  variable's  value  1.  printed  by  entering  its  nau.e  synibollcally.  using  its  «,urce  cod.  nan.e.  If 
1  variable  is  a  retnni.  it.  value  is  printed  using  on.  line  per  Eeld.  Poster  values  are  pnnted 

as  numerical  addresses. 

Tbe  extension  to  DBX  described  in  this  teport.  which  presents  daU  struaures  g,eph,=.ny 
and  allows  user-tailorability,  will  be  referred  u.  asODBX.  for  Graphicl-DBX. 

To  schreve  the  prevrously  described  goaU  of  improved  debugger  presentat.on,  the 
graphics  extension  prqiect  set  the  following  objectives: 

.  A  variable's  value  should  be  presented  in  bo..o,.de.rrom  format.  Structures  and  nested 
Structures  should  present  information  and  dependenoes  clearly. 

.  A  variable's  value  should  be  updated  after  each  eseearron  srep,  with  danges  t^ly 
ident.6«i.  (An  erecurion  step  means  any  further  execution  of  the  program  being  de  ugg 
This  mav  result  from  such  DBX  commands  as  STEP,  NEXT,  CONT,  CALL,  or  RUN. 

.  Users  should  be  able  to  control  the  amount  of  informi.tion  presented  about  a  data  structure 
aud  its  layout  on  the  screen,  even  before  beginning  to  debug  a  program. 

.  Users  should  be  able  m  change  the  presenution  of  a  data  structure  by  openmg  or  closing 
telds  of  a  record,  by  moving  structures  or  arrows,  or  by  scrolling  arrays. 

.  The  data  structures  should  be  displayed  on  a  vurael  screen,  larger  ^ 

The  virtual  screen  should  be  scrolioble,  allowing  the  visible  portion  of  the  screen 

moved  up'down  or  lefUright. 


6.  Related  Work 

■Model  791  and  IMyere  80!  give  a  history  of  debuggers  and  defend  the  use 
display  for  data  structures.  An  orrofr^iori  display  is  one  U.at  makes  uae  “f 
grapbim  to  present  objects  m  the  form  of  boxes.  arn>wa  or  icons,  creating  analogs  to 

physical  wo-ld. 

The  work  most  doselv  related  to  GDBX  was  done  by  Myere  at  Xerox  PARC.  ENCEX 
tMyere  80)  was  perhaps  the  first  system  to  pre^nt  graphical  displays  of  daU  strectures  m  a 
sUndard  compiled  language  using  a  bit-mapped  display. 

tNCENSE  displays  data  structures  in  b„x.oade,rr,a.  format,  with  box^  linked 
arrows.  INCENSE  includes  a  mechanism  that  allows  users  to  deine,  by  a  Mesa  program, 
presentation  format  of  a  record  structure. 

The  placement  of  linked  structures  is  accomplished  usuig  what  Myers  calls  a J^ur 
mechanism  The  mechanism  gives  Ml  objecm,  at  the  time  of  them  oeatron,  a 

area  in  which  to  display  themselves.  Parts  of  a  linked  data  structure  that  are  pointed  to  must 
find  a  space  for  ttiemselves  within  this  area.  Thus,  components  further  down  the  potn^r  *a^ 
shrink  themselves  to  fit  into  the  designated  area.  Beyonu 
structures  do  not  present  themselves. 
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0»x  extend,  the  ,de.  ef  greph-cnl  ptesentefon  of  deu  «roct^  in  .be  .pint  of 
D.CXNSE  Areas  in  .h.ch  GDBX  improves  upon  mcENSE  solutrons  are  the 

ndani  debugger.  GDBX  is  an  extension  to  a  standard  debugge  , 

.  Integrafon  mto  a  tand^  ^  ^  „CE.NSE 

Tn:.  ::r:  m  -rTd.  i.  .hooM  .case  ..  ..eotiveness  of  an,  deho^er 

.to.h.chitm.,htheinte^.^-|Mye.SO,M,^^  ,  two^..e„siona.  space  a.itnat.on 
o  Two-dimensional  space  alloca  .  ,  ,  r«a«  on  the  screen.  ENCENSE  shied 

a.^tm'l'^'lot^^n 'nndteC 

JneraTand  can  be  extended  to  incorporate  a  speciaiised  pUcement  rout.ne 
GPBX  introdoces  the  following  ideas  to  graphical  debugger  displays: 

.  Dynamic  user  control  over  data  structure  presentation:  OPENCEOSE.ng  of  reco  - 

array  elements,  moving  structures  and  arrows  scrollmg  arrays 

.  Scroll  bars  and  a  virtual  screen  srray3EGIN, ARRAY-SEE, 

.  Construction  and  presentation  control:  SHOWdlNSHOW,  PTA^EPTH,  ABBAY-BE 

SUPPRESS  UNSUPPRESS 
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6  Illustrations  of  Graphic  Presentation 

section  confin.  dumps  from  .  Sun  Workstation  tak.n  during  *saio|m  with 

GDBX  Those  «roon.  show  how  daU  structures  are  presented  and  show  operatmns  perform 
upon  the  data  structures.  They  illustrete  how  GDBX  meets  the  objectives  outlined  above, 

(Please  refer  to  section  ^  and  the  «xN  page  in  the  appendix  for  a  more  detailed  discusaion 
of  the  GDBX  commands  and  mouse  operations  used  in  making  these  screens) 

There  are  10  sutrsections  illustrating  the  following  displays  and  operations: 

6.1  Display  of  Data  Structures  in  C  and  Pascal 

6.2  Construction/Modification  of  Linked  Data  Structures 

6.3  across  DOWN  Layout  Specification 

6.4  OP':N'CLOSEmg  of  a  Record  Field 

6.5  Structure  Movement 

6.6  Arrow  Movement 

6.7  Array/Pointer  Ellipsis 

6.6  Array  Scrolling 

6S  Array  Suppression 

6.10  Scroll  Bars  and  Font  Changes 
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6.1.  Display  of  DaU  Structures  in  C  and  Pascal 

H,.  following  sooons  fflurtroto  how  data  *ructur«  are  proaentod  in  C  M.d  PaKah  The 
preeentation  of  a  data  atruaure  i.  identical  in  the  two  langnagee,  with  the  eiceptK.n  of  type 
names  and  scalar  types  of  Pascal. 


611  This  screen  shows  the  paradigmatic  box  form  in  which  mmple  varmbles  are 
presented.  The  variable’s  name  is  shown  on  the  left  side  of  the  ho,  and  its  value 
on  the  right.  A  variable  of  pointer  type  is  represented  by  a  value  of  and  an 
arrow  emanating  horn  the  right  side  of  the  bo,.  Here.  C  variables  of  type 
integer,  diaracter,  real,  string,  and  pointer  are  presented. 

61i  This  screen  presenu  Pascal  variables  of  type  Integer,  character,  boolean,  r«l, 
scalar  type,  pointer,  and  record.  A  record  ie  presented  using  nested  boxes.  Ilie 
record  itself  is  an  enclosmg  box.  The  Selds  of  a  record  are  shown  as  boxes 
stacked  vertically  within  the  outer  box. 


613  This  screen  Ulustrates  an  array  of  strings  an  array  of  pointers,  an  array  of 
integers,  and  a  twodimensional  array.  The  presentation  of  arrays  is  similar  to 
records.  An  array  is  shown  as  an  enclosing  box.  Each  element  of  the  array  is 
displayed  in  a  separate  box  stacked  vertically  within  the  box  representmg  t  e 
array.  The  element  number  is  shown  in  brackets  after  the  array  name. 

6.1.4  This  screen  shows  an  array  of  pointer,  an  array  of  integers,  a  record,  a  nested 


record,  and  a  recursive  structure. 

6.1.5  This  screen  shows  a  three^imensional  array  of  scalar  literals  in  Pascal. 
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6i.  Constructioa'Modification  of  a  Linked  Data  Structure 

The  following  screens  illustrate  a  program  executed  one  step  at  a  time  using  DBXTOOL 
and  GDBX.  The  program  constructs  and  modifies  a  linked  data  structure. 

DBXTOOL  appears  on  the  right  with  five  sub  windows.  (See  InUgration  wUh  DBXTOOL 
below.)  A  breakpoint  that  has  been  set  is  indicated  by  a  stopsign.  The  current  execution  stop  is 
shown  by  a  double-shafted  arrow.  The  program  is  executed  one  step  at  a  time  by  clicking  the 
step  button  in  the  third  subwindow. 

As  each  step  is  executed,  the  data  structure  is  updated  in  the  GDBX  window  on  the  left. 
This  series  of  screens  illustrates  how  the  progress  of  a  program  can  be  seen  visually. 


ftruct  r*curil  •  r»cur»lv«l  ; 
ttruct  r*cur»2  •  r*cur»iv*2  ; 


ptcur»i»»  s  (ttruct  rtcur*  ■  )  e«noc(  1, 
ttruct  r*euri))  ; 
r«eurtlv#->n*Kt  *  r»ciir»ly«  ; 

r»cur*l»*l  =  (ttruct  rteurtl  •  )  ct11oc(  1,  tlzte 
1<  ttruct  rteurtl))  ; 
rteurtl vtl->ntKt2  =  rteurtl vtl  ; 


rtr  e  (ttruct  trtt  »  ) 

^  ctnpcC  1,  tUtotC  ttruct  trtt  ))  ; 

ptr->1ttt  :  4  ; 

ttr->1tft  s  (ttruct  trtt  •  ) 

ctnoc(  1.  t1ztof(  ttruct  trtt  ))  ; 
ptr->r1grt  i  (ttruct  trtt  •  )ptr->left  • 


nttBiriQ  lytboUe  intortttior. 
i(<eto  131  tytbolt 
^(abKtool)  ttbp  tt  K 
:;i)  ttof  tt  ■trtt.c*:96 
'dbxtbcl)  run 
flbxtocl)  print  ptr 
''abxtoo))  aitpity  ptr 
abxtoo))  I 


Screen  6.2.1 


t^iptc  tt  lint  96  in  function  tain 

ourca  ditpityta: 

ttruct  rteurtl  •  rteurtl vtl  ; 
ttruct  rtcurtZ  •  rteurtl vt2  ; 

r^curtlvt  c  (ttruct  rtcin  •  )  ctDocC  1,  t1itef( 
ttruct  rtcurt))  : 
rteurtl  vt->ntxt  t  rtartivt  ; 

rtcurtivtl  =  (ttruct  rteurtl  •  )  ctlloeC  1,  tirto 
f(  rtruet  rteurtl))  ; 
rteirtivtl->n«t2  =  rtcirtlvtl  ; 


■tr  t  (ttruct  trtt  •  )  _  . 

f  ctDocC  1,  tlitcfC  ttruct  trtt  ))  . 
^ptr->ittt  s  4  ; 

ttr->1tft  s  (ttruct  trtt  •  )  _ _ 

ctnoc(  l,  tlztef(  rtnict  tr«  ))  , 
r->r1gnt  -  (ttruct  trtt  »  )ptr->1tft 


ttaing  tytbollc  lirfortttion. 
nttd  131  tytbolt 
i(dbrtool)  ttop  tt  K 
!!)  ttop  it  ■trtt.c*:* 
dPKtoel)  nti 
dbxtool)  print  ptr 
dbxtocD  titpitj  ptr 
idbxtoo))  tttp 
idpxtool)  I 


;-ourtt  dupltytd:  flit  ./trtt.c  llntt  92  -  118 


ptr  =  (ttruct  tr«*  •  ) 

f  c<lloc(  1,  slztofC  itruct  tTM  )) 
ptr->1tw  s  4  ; 
ptr->1#tt  s  (»truet  trw  •  > 

i^ca11oc(  1.  •1z*of(  ttruct  trtt  }) 
ptr->r1Bht  s  (ttruct  trtt  •  )ptr->1fft 
ptr->lttt->ittt  =  8  ; 
ptr->1tft->1ttt  s  (ttruct  trtt  •  ) 

ctHDC(  I,  t1ztof(  ttruct  trtt  )) 
ptr*>ltft->rl9ht  :  (ttruct  trtt  •  ) 
c«11oc(  1,  tlztof(  ttruct  trtt  )) 


v^-v.i  HI 


r-.  rii^4.»f5 


oppta  it  lint  IBi  in  function  ttin  in  fi  It  ./trtt. 
iouTt  ditpitytc:  file  ./trtt.c  tints  9?  -  IIB 


rtcurnvtl->ntxt2  •  rtcuriivti  ; 


ptr  s  (ttruct  trtt  •  ) 

f  ctnoc(  1,  tizterfC  ttruct  trtt  )) 
ptr->lttt  s  4  ; 
ptr->tt^t  =  (ttruct  trtt  •  ) 

etnocC  nztof(  ttruct  trtt  )) 
■^ptr->npnt  s  (ttruct  trtt  •  )ptr->1tft 
ptr->ttft->1ttt  :  S  ; 
ptr->ttft->ttft  s  (ttruct  trtt  •  ) 

ctnoe(  1,  tlztof{  ttruct  trtt  )) 
ptr->ttft->rlgtit  o  (ttruct  trtt  •  ) 
ettlocC  1,  tl2tof(  ttruct  trtt  )) 


etOlng  tytOolu  tnfortttlon. 

ttd  131  tyttolt 

acictool)  ttop  tt  K 

i)  ttap  tt  “trtt.c*;* 

tbirtool)  run 

aOKtool)  print  ptr 

OBxtool)  ttipity  ptr 

SbirtMl)  tttp 

dbxtoot)  ittp 

tbxtool)  tttp 

dbxteol)  I 


.-lopp»o  »t  iin*  in  luncxion  »»in  in  111*  ./Xr*t.c 
lourt*  tfitPlPy**!!  ./trtt.c  11n*t  82  -  IH .  _ 


r*curtiv*l->n*><t2  i  ricuriivil  ; 


ptr  s  (»tnict  tr**  •  ) 

f  e*noc(  1.  »lz»irf(  •truct  trw  ))  ; 
ptr->1t**  ~  *  ; 

■tr->lrft  =  (ttruct  trw  •  ) 

C»noc(  1,  tlzPofC  •truet  tr**  ))  ; 
ptr->rigM  s  (»truct  trw  •  )ptr->1*ft  ; 
iiAptr->1tft->1t**  I  8  ; 

ptr->1»<t'>Uft  :  (itruct  tr**  »  ) 

c»noc(  1,  »1z*of(  »trutt  tr**  ))  ; 
ptr->1*ft->rlBht  =  (struct  tr**  •  ) 

c»noe(  1.  »lz*ot(  struct  tr**  ))  ; 


e»aing  *y*Bclic  intorMtion 
e*d  131  sy*bBl* 
dpxtoot)  stop  *t  K 
1)  stop  *t  "trss.c":* 
aoxtoet)  run 
aoxtooU  print  ptr 
aoxtoot)  *i*p1»j(  ptr 
aoxtool)  *t*p 
aoxtoot)  st*p 
aoxtooD  *t*p 
aoxtooD  st*p 
floxtoci)  ■ 


Stoppio  St  1in*  164  in  function  sain  in  fi 1*  ./tr**.c 
Sour:*  Si»p1*ytS;  fll*  ./trss.c  llnss  S?  -  116 _ 


r*cursiv*l->n«xt2  :  rscursivti  ; 


ptr  :  (struct  tr**  •  ) 

f  c*noc{  I,  ni*of(  struct  tr**  ))  ; 
ptr'^lt**  :  4  ; 
ptr->1*ft  =  (struct  tr**  •  ) 

c*noe(  I,  *i**of(  struct  tr**  ))  ; 
ptr->rijnt  s  (struct  trs*  •  )ptr->1*tt  ; 
ptr->l*ft->lt**  =  5  ; 
ptr->l*tt->1*ft  =  (struct  trs*  •  ) 
-^c*l1oc(  1,  *1z*of(  struct  trs*  ))  ; 
ptr->1*ft->nBht  =  (struct  trs*  •  ) 

eal1oc(  i(  *1zsof(  struct  tr**  ))  ; 


ii*»C  131  sysbol* 
^rdbxtool)  stop  It  K 
1)  stop  >t  *trM.c*:K 
dbxtool)  run 
ooxtool)  print  ptr 
dbvtool)  Pispl^  ptr 
dbxtool)  stap 
dbxtool)  stop 
dbxtool)  stop 
dbxtool)  stop 
dbxtool)  stop 
dbxtool)  I 
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6J.  ACROSS  DOWN  Layout  Specification 

The  following  screens  show  the  linked  structure  constructed  in  the  previous  program 
displayed  first  ACROSS  and  then  DOWN  the  screen. 
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6.4.  OPEN/CLOSEing  of  a  Record  Field 

The  following  screens  illustrate  an  operation  on  the  linked  structure  constructed  above. 

A  field  of  a  record  is  first  selected,  then  CLOSED  or  OPENED. 

6.4.1  The  linked  data  structure  is  displayed  ACROSS  the  screen. 

6.4.2  Clicking  the  left  mouse  button  while  pointing  at  a  box  selects  and  highlights  the 
top-level  structure.  Here,  the  second  box  is  selected. 

6.4.3  Clicking  the  left  mouse  button  within  a  highlighted  record  structure  selects  a 
field  within  the  structure.  Here,  the  field  named  right  is  selected. 

6.4.4  Depressing  the  right  mouse  button  summons  a  menu  of  operations  that  may  be 
applied  to  the  selected  record  field.  Here,  the  operation  Close  Selection  is  chosen. 
As  illustrated,  the  field  named  right  is  closed  and  the  pointer  and  strurture 
emanating  from  it  are  erased.  A  closed  pointer  is  indicated  by  the  value 

6.4.5  The  closed  record  field  right  is  once  again  selected. 

6.4.6  A  menu  is  called  and  the  operation  Open  Selection  is  applied.  This  re-opens  the 
right  field,  and  the  structure  to  which  this  field  points  is  once  again  displayed. 
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6JS.  Structure  Movement 

The  following  *r«ns  illustrate  how  the  middle  mouse  button  is  used  to  move  stniotures 
on  the  screen. 

6.5.1  This  screen  illustrates  a  layout  of  an  array  of  pointers  created  by  the  positioning 
algorithm. 

6  5.2  To  move  a  structure,  the  middle  button  is  depressed  while  pointing  to  the 
structure  Here,  the  array  of  pointers  was  pointed  to.  Moving  the  mouse  while 
continuing  to  depress  the  middle  button  dregs  an  outline  of  the  structure  along 
with  the  mouse. 

6.5.3  When  the  middle  button  is  released,  the  array  structure  is  displayed  at  its  new 
position. 
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6^.  Arrow  Movement 

He  Mewing  Bcn*n.  Ulustmte  bow  en  .m.w.  which  represents  .  pointer,  can  be  mov^. 
The  actual  value  of  the  pointer,  as  well  as  the  screen  represenution,  re  modiSed  by  movmg  the 


arrow  to  point  to  a  different  object  on  the  screen. 

a  ■  ■  a— ^  vorinhlfa^  each  of  which  has  two  fields  that  are 

6.6.1  This  screen  presents  three  tree  vanaoies,  eacn  oi  wuit^ 


6.6.2 


pointers  to  other  trees.  "Hie  fields  are  currently  nil. 

To  move  an  arrow  <or  to  create  an  arrow  if  the  current  value  is  niT.,  the  box 
holding  the  pointer  is  firet  selected  using  the  left  mouse  button.  Here,  the  o  field 


of  variable  x  is  selected. 

6  6  3  If  the  middle  button  is  depressed  when  a  pointer  field  is  the  current  selection,  the 
arrow  will  be  moved.  This  screen  illustrates  a  new  arrow  followmg  the  motion  of 


the  mouse. 

6.6.4  The  new  arrow  is  positioned  to  point  to  the  structure  xl 

6  6.5  If  the  arrow  is  positioned  to  point  to  a  record  structure,  the  user  selects  which 
field  within  the  record  he  would  like  the  arrow  to  point  to.  Here,  the  entire 
record  xl  is  selected.  The  value  of  pointer  o  is  changed  and  the  screen  is  updated 

to  reflect  its  new  value. 

6,6.6  This  screen  Ulustrat«  the  three  recoids  after  field  c  of  a  is  made  to  pomt  to  a2. 
Recursive  structures  may  also  be  defined  in  this  way. 
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6.7.  Array/Pointer  Ellipsis 

The  following  screens  illustrate  ellipsis  of  array  elements  and  of  linked  structures  beyond 
a  certain  depth. 

6.7.1  This  screen  illustrates  an  array  for  which  only  the  first  five  elements  are 
presented.  This  ellipsis  is  accomplished  by  either  the  ARRAY-SIZE  or  PRINT-SIZE 
command.  The  element  value  indicates  elision.  The  number  of  array 
elements  that  are  constructed  is  set  by  ARRAY-SIZE.  PRINT-SIZE  sets  the  number 
of  array  elements  to  be  presented. 

6.12  This  screen  Ulustrates  a  linked  list  of  structures  that  is  displayed  only  to  a  depth 
of  five.  Ellipsis  such  as  this  is  accomplished  by  either  the  PTR_DEPTH  or 
PRINT-DEPTH  command.  A  pointer  value  indicates  an  elision  caused  by 

PTRJDEPTH.  A  pointer  value  (not  shown  here)  represents  an  elision  caused 
by  limiting  the  PRINT-DEPTH  of  a  pointer.  The  latter  elision  is  equivalent  to  a 
CLOSED  box.  A  linked  structure  thus  elided  may  be  OPENED  to  display  subsequent 
levels. 
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6^.  Array  Scrolling 

The  following  screens  illustrate  how  an  array  may  be  scrolled. 

6.8.1  This  screen  illustrates  an  array  for  which  only  the  first  five  elements  are 


6.8.2 

6.8.3 


displayed. 

Here,  an  element  of  the  array  is  eelected  using  the  left  mouse  button. 

Depressing  the  right  mouse  button  calls  a  menu  from  which  the  operation 
SCROLL  SELECTION  TO  TOP  U  selected.  The  selected  element,  number  4.  m  scrolled 
to  the  top  portion  of  the  visible  array.  The  beginning  element  of  an  array 
presentation  may  also  be  set  using  the  command  PEINT^EOPi.  print.s,ee  sets 
the  number  of  array  elements  that  are  shown. 


V  ?i'’.-i  ^  1  "'.v  s  w, 

/  •,  '  ^  V.  /  \  ^ 

^.<yX-5f/*J<<WW''v:<'J;^’;X:tf*X^;iy;;J 

^  •'>''*•,  s  s'>  <  s  .*/  ^  •*' 

■5  '  •■  5,  V  '  '■'■  '’'’ 


i.  ,;‘^r  '''•^^  5^, 

va  4,'-^/ '■■'S«'> 

i  '  L'-' %:<  ' 
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63.  Array  Suppression 

This  screen  pictures  two  arrays  of  identical  values  The  left  array  is 
presented  normally.  All  values  are  show,  up  to  the  portion  that  is  elided  due  to 
PRINT^EE.  In  the  right  array,  the  0-valued  elements  of  the  array  are  elided  by 
the  command  SUPPRESS. 


/I:  ^ 
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■^v 
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trriy[3]:  3 


irriy[53:  5 


•rri^[6]_^ 

»rr»y[7]:  1 


•rr»^C63j_^ 

■rr>y[9]:  9 
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8.10.  Scroll  Bars  and  Font  Changes 

The  following  screens  illustrate  how  large  data  structures,  or  many  data 
structures,  may  be  viewed  on  a  small  screen.  The  visible  screen  can  be  scrolled, 
presenting  different  portions  of  the  virtual  screen.  Alternatively,  the  font  in 
which  data  structures  are  shown  may  be  changed  to  shrink  or  enlarge  the 

presentation. 

The  data  structure  shown  is  that  of  an  option.subwindow.  a  standard 
sub  window  structure  in  SunW  indows. 

6.10.1  This  screen  shows  a  linked  option^ubwindow  structure  that  does 
not  fit  on  the  screen.  The  mouse  is  positioned  in  the  top  horuontal 

scroll  bar. 

6.10.2  After  clicking  the  left  button,  the  portion  of  the  virtual  screen 
presented  is  shifted.  The  presented  portion  of  the  screen  now 
begins  at  the  mouse’s  position  in  the  scroll  bar. 

6.10.3  Here,  a  smaller  font  is  chosen.  With  the  entire  data  structure 
scaled  down,  the  linked  option subwindow  fits  inside  the  visible 
portion  of  the  screen. 

6.10.4  This  screen  illustrates  the  data  structure  presented  in  a  larger  font 


size. 
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7.  Command  Description 

Commands  to  present  or  modify  data  structures  graphically  may  came  ftam  the  keyboard 
or  the  mouse.  Commands  entered  at  the  keyboard  will  be  refmred  to  as  GDBX  commands. 
ODEX  commands  include  the  standard  DBX  commands  which  are  unmodified.  GDBX  common  s 
can  be  issued  before  beginning  U.  debug  a  program  mteractively.  Mouse  commands  operate  on 

structures  already  displayed. 


7.1.  GDBX  Commands 

GDBX  commmrds  may  be  issued  during  interactive  debugging,  or  may  be  placed  in  an 
initialisation  file.  If  the  commands  are  placed  in  the  startup  MM  file,  they  are  read  and 
processed  St  the  beginning  of  each  GDBX  session.  This  mechanism  can  be  u^  to  define  an 
environment  tailored  to  an  individual  user.  (The  same  mechanism  is  used  m  the  ongmal  DBX. 

If  the  commands  are  plac«i  in  a  file  named  MxfiU  Iwhere  file  is  the  name  of  the  program  In  be 
debuBgedl  thev  are  rmid  and  processed  only  when  this  particular  program  is  debugged.  This 
second  usage  creates  an  environment  tailored  to  a  particular  program  and  the  data  structures 

within  it. 

7.1.1.  Presentation  Commands 

display  variable-name  [  ,  variable-name  1  ,  .  ...j  k^v 

prSSS  M  t°L  execution  stops,  after  a  STEP^XT,  or  CONT^  “ns““ 

^ition  of  DiSPLAYed  dau  structures  is  maintained  across  execution  step  . 

UMjisplay  variable-name  [  ,  variable-name  1 

UMilSPLAY  clears  the  variable’s  value  from  the  sc^n  and  removes  it  from  the 
of  variables  that  are  updated  after  each  execution  step. 

PRDvT  variable-name  [  ,  variable-name  i 

PRINT  present*  the  variable’s  value  on  the  screen  m  the  same  manner  as  DISPLAY. 
p^Ted  variables  are  erased  from  the  screen  after  each  execution  step. 

ERASE  variable-name  [  ,  variable-name  1 

ER.-^E  clears  the  variable’s  value  from  the  sexeen.  The  entire  screen  can  also  be 

cleared  (see  CLEAR  below). 


7.1.2.  Layout  Commands 


ACROSS  structure-name  [  ,  structure-name  1 

across  causes  pointers  to  succeeding  boxes  of  a 
screen.  The  default  direction  is  ACROSS. 


linked  structure  to  point  across  the 


DOWN  Structure— name  (  ,  structure— name  1 

DOWN  causes  pointers  to  succeeding  boxes  of  a 
screen. 


linked  structure  to  point  down  the 
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7.1  Command*  Limiting  Construction  or  Presentation 

In  presenting  a  data  structure  on  the  screen.  GDBX  first  construcU  boxes  to  represent 
the  data  structure’s  value  and  then  pnsenta  these  boxes  on  the  screen.  The  user  can 
control  the  amount  of  information  GDBX  processes  at  either  the  construction  or 
presentation  phase.  Limiting  the  amount  of  information  constructed  by  GDBX  increases 
the  speed  with  which  data  structures  are  presented  and  conserves  memory.  Limiting  the 
amount  of  information  presented  on  the  screen  increases  presentation  speed  and  decreases 
the  amount  of  information  shown  on  the  screen. 

Construction  is  done  only  in  response  to  a  PRIOT  or  DISPLAY  command.  Only 
constructed  boxes  can  be  presented. 

There  are  three  data  structure  types  that  can  grow  very  large  for  which  limitation 
may  be  important:  records,  arrays,  and  linked  (pointer)  structures.  GDBX  commands  exist 
to  limit  processing  of  these  three  types  during  construction  and  presentation  phases. 

7.U.I.  Record* 

SHOW  UNSHOW  are  used  to  specify  the  fields  of  a  record  for  which  information  is 
constructed  Without  any  specification,  all  fields  of  a  record  are  constructed.  'The  mouse 
commands  OPEN/CLOSE  (see  below i  control  which  fields  are  presented  on  the  screen. 


SHOW  field-name  I  ,  field-name  1 

SHOW  is  called  with  a  field-name  of  a  record  structure  tj^  (e.g.,  SHOW  tree.inght). 
SHOW  causes  a  box  for  the  given  field  to  be  constructed  the  next  time  a  vanable  of 
this  t\T>e  is  PRiNTed  or  DiSPLAYed.  Only  fields  that  are  SHOWn  will  be  instructed; 
all  fields  not  explicitly  SHOWn  will  be  suppressed.  The  SHOW  command  is  us^  to 
focus  attention  on  a  few  particular  fields  of  a  large  record  structure.  SHOW  s  affects 
all  variables  of  the  given  type. 


UNSHOW  field— name  [  ,  field— name  1 

UNSHOW  is  called  with  a  field-name  of  a  record  structure  type.  A  box  ^11  not  be 
constructed  (or  presented',  for  this  field  the  next  time  a  vanable  of  this  is 

PRTNTed  or  DiSPLAYed.  The  UNSHOW  command  is  used  to  suppress  particular  helds 
that  are  not  of  interest.  SHOW  and  UNSHOW  are  not  exact  antonyms:  SHOW  entails 
that  fields  left  unspecified  will  be  suppressed,  whereas  UNSHOW  enUils  that 
unspecified  fields  will  have  boxes  constructed. 


7.I.3.2.  Array* 

aRRAY_BEGIN.'ARRAY_SIZE  control  the  starting  element  and  number  of  array  elements 
for  which  boxes  are  constructed.  PRINT_BEGrN/PRINT_SIZE  control  where  the  presentation  of 
array  elements  begins  and  how  many  elements  are  shown.  An  array  can  also  be  scrolled 
(see  SCROLL  SELECTION  below)  to  change  the  beginning  element.  SLTPRESSUTNSUPPRESS 
control  the  construc^n  of  0-valued  array  elements. 


arraY-BEGIN  array-name  integer 

ARRAY-BEGIN  sets  the  element  number  from  which  construction  of  boxes 
representing  array  elements  begins.  The  default  starting  element  number  is  0. 
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r:X  or  ...on.  ror  «...  .xos  ...  oo,,..-..  for  ..0 

^  array  variable.  The  default  array  oze  is  10. 

X  JS  .oeo  sc«o.  s.™ 

below). 

PRlNTjnx  arroy-name  m«g« 

PRINT-SIZE  sets  the  number  of  elements  tnat  wui  oc 
variable.  The  default  print  size  is  10.  . 

SUPPRESS  array-name  elements  whose  values 

SUPPRESS  instructs  GDBX  to  suppress  construction  of  array  elemenis 

are  0  or  nil. 

UNSUPPRESS  array-name  ^  ,ven  those  arrav  elements  whose  values  are 

UNSI.TPRESS  instructs  GDBX  to  construct  even  those  arra. 

0  or  nil.  This  is  the  default  condition. 

7  mu.  Linked  (Pointer)  Structure* 

pn^EPTH  contrau  the  oumber  of  pointer  levels  constn.c^  whereas 
»„t.nu  the  nno.h.r  presented,  Ehsion  due  to  limiting  is  eguivalen.  m 

CLOSEd  box. 

PTIt_DEPTH  ptrjiame  integer  coeslrucred  for  the  given 

PTRnEPTH  sets  the  number  of  pointer  . 

The  default  pointer  construction  depth  is  5. 

PEr.T_DEPTB  ptr.j.an.e  integer  ^ 

SfvSlhT.“  ^^e  SSul  plTdept'h  is  6,  The  number  of  levels  presented  may 
^  be  controUed  by  OPENING  or  CLOSING  pointers. 

7i.  Mouse  Commands 

e-  crp  initiated  from  the  3-button  mouse  when  it  is  pointing  mto 
The  following  operations  are  mitiatea  xrom  lu 

the  graphics  window. 

7i.l.  Left  Button 

Clickine  the  left  button  while  pointing  into  a  structure  selects  that  structure  or  a 
held  ™  T;e  structure  selected  is  called  the  current  sclechon,  Mu.tip^lc^-^e 
^mcture  will  cycle  through  nested  fields  within  the  structure.  A  selected  stnn^ 
Tthen  be  ected  upon  Isee  the  Seiecrmn  Menu  below).  Clicking  the  left  button  outside 

a  structure  clears  the  current  selection. 
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CUcking  the  left  button  while  it  is  in  the  horizontal  or  vertical  scroll  bar  causes  a 
new  portion  of  the  virtual  screen  to  be  presented.  In  the  scroll  bar,  the  dark  gray 
rectangle  represents  the  size  of  the  entire  virtual  screen;  the  white  recungle  represents 
the  currently  displayed  portion.  The  new  portion  to  be  displayed  is  determined  by  the 
position  of  the  mouse  within  the  scroU  bar  when  it  is  clicked. 

Clicking  the  mouse  in  the  top  left  hand  box  resets  the  portion  of  the  screen 
presented  to  be  the  upper  left-hand  comer. 

7,2^.  Middle  Button 

The  middle  button  is  used  to  move  structures  or  unuws.  If  a  pointer  value  is  not 
the  current  selection,  depressing  the  middle  button  will  move  the  atructure  to  which  the 
mouse  ia  pointing.  Moving  the  mouse  while  holding  the  middle  button  down  drugs  the 
structure  along  with  the  mouse.  The  structure  U  re-positioned  to  the  mouses  position 
when  the  middle  button  is  released. 

If  a  pointer  value  is  the  current  eeleclion,  depressing  the  middle  button  moves  the 
arrow  emanating  hum  the  selected  box.  The  structure  pointed  to  by  the  mouse  when  the 
button  is  released  becomes  the  new  value  of  the  pointer.  If  a  reconi  structure  m  pointed 
to  the  left  button  is  used  to  select  which  held  the  arrow  should  point  to. 


7JJ.3.  Right  Button 

Depressing  the  right  button  preeenu  several  banks  of  menus.  The  banks  and  their 
commands  are; 

7.2.3.1.  General  Commands 

.  ctEAR:  Clears  the  entire  screen  of  both  PRiOTed  and  MPwyed  structures.  Sets  the 
po^oi^f^fvtttual  screen  presented  to  be  the  upper  left-bund  comer. 

•  QUIT:  Closes  the  widow  and  causes  GDBX  to  exit. 

7 .2.3.2.  Selection 

The  followung  commands  operate  on  the  correnl  selection  (see  Left  Button  abovei. 

.OPEhV  Causes  the  selected  structure,  held,  or  array  element  to  be  presented  normally. 

.  close:  Causes  the  seleriion  to  ‘Ltb^m^ureTrepW 

i‘y“ufe".^rLprayed  in  small  font.  If  the  box  la  a  pointer, . ia  presented  in 

the  box,  indicating  a  suppressed  pointer. 

’ao'Taf'thuiSient™ ’top“yrf  “"Sf  t^'tlf  “e"S4y'''Thm‘’is'^t,^atent  to  the 

ARRAY-BEGIN  command. 

.  SCROLL  SELECTION  TO  BOTTOM:  If  the  Selected  box  is  ^  array  element,  the  array  is 
scrolled  80  that  this  element  is  displayed  at  the  bottom  of  the  array. 
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Font* 

A  font  with  which  to  present  ealues  within  boxes  is  selected.  When  a  new  font  is 
chosen,  the  graphic  window  is  cleared  and  all  DiSPLAVed  variables  are  presented  m  the 

new  font. 

7.2.3.4.  Show  Changes 

This  series  of  commands  emphasizes,  by  blinking,  changes  to  the  values  of 
DISPLAYed  variables  that  occurred  over  the  last  execution  step. 

.  bunk  n-ew:  The  new  values,  i.e.,  the  values  different  from  the  previous  values,  of  the 
DISPLAYed  data  structures  are  made  to  blink. 

.  BUN-K  ou>;  The  old  values  of  the  DBPLAVed  data  structures  are  made  to  hlink. 

.  BUN-K  OUJN-EW:  The  values  within  the  dau  struaures  DlSPUaVed  are  made  to  blink 
between  previous  and  current  values. 


8.  Implementation 

8.1.  Overview  and  Processes 

The  graphic  version  of  DBX  (GDBXJ  is  implemented  using  three  processes.  GDBX  is  the 
initial  program  executed.  GDBX.TOOL  ia  forked  by  oliBX  and  GDBX.ABO.  is  in  turn  forked  by 
GDBX.TOOL.  Integration  with  DBXTOOL  requires  a  multiple-window  implementation  for  GDBX. 
Multiple  windows,  in  turn,  requires  multiple  proresses,  because  m  Sunffindoios  ^ch  window 
ha.  an  underlvtng  process.  The  processes  communicate  ustng  the  UNIX  pipe  mechanism,  and 
synchranixe  using  the  SELECT  system  call.  Following  is  an  overeiew  of  the  three  processes. 

*  GOBX 

GDBX  is  execute!  from  the  shell  with  the  command  DBX  -G  or  is  forked  by  DBXTOOL  (see 
fntegrenon  lefr/i  DBXTOOL  below).  GDBX  ireates  s  socketpair  (two  pipes),  then  forks  GDBXJTOL. 
passing  to  it  the  die  descriptors  of  the  socketpair.  After  the  socket  has  been  formed.  GDBX  does 
a  SELECT  svstem  call  and  waiu  for  input  either  from  the  keyboaid  or  the  mouse. 

■me  GDBX  commands  BRtNI  and  DEBLAY  create  a  Sruaure  that  represenu  the  value  of 
the  variable  (data  structure)  to  be  displayed  on  the  screen.  After  the  sire  of  the  data  structure 
and  its  position  on  the  screen  have  been  determined,  commands  to  present  the  data  structure 
are  sent  to  GDBXLSHOW  acmes  the  pipe.  Other  GDBX  commands,  mich  as  acrossdown, 
SBOWT.-NSHOW,  ETBUIEPTH,  or  ABKAYU.EGDOABKAY31ZE,  affect  the  constructs  of  the  daU 
structure  representation  or  its  positioning  on  the  screen.  Original  DBX  commands,  unrelated  to 
presenting  a  variable’s  value,  are  unaffected  by  GDBX. 

Input  from  the  mouse  is  received  by  GDBX  through  the  pipe  from  GDBX^HOW. 
ia  interpreted  by  GDBX  and  the  appropriate  response,  usually  a  wreen  update,  i.  tulculated  and 

sent  back  to  GDBX-SHOVr  for  display. 
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GDBX  mainuin.  .11  th.  mformation  .boul  the  data  atmcturea  displayed  and  about  the 
display  itself,  such  as  the  font  size  «.d  the  part  of  the  virtual  screen  currently  displayed. 

•  GDBX_TOOL 

GDB>L.TOOL  IS  forked  by  GDBX.  This  process  opens  a  window  on  the  screen,  and  creates  a 
tty  and  a  graphics  subwindow.  GDBXJTOOL  passes  the  socketpair  file  descriptors  it  has  received 
GDBX  on  to  GDBX^HOW  when  it  forks  this  new  process.  After  creating  GDBX3HOW 
GDBX_TOOL  is  no  longer  involved  in  GDBX  processing.  However,  it  does  retain  global  too 
functions  such  as  CLOSE,  which  turns  the  window  into  iconic  form,  and  QUIT,  which  ends  the 

process. 

•  GDBX_SHOW 

GDBX^HOW  is  forked  by  GDBX.TOOL.  It  receives  a  pair  of  file  descriptors  through  which  it 
communicates  with  GDBX.  GDBX^HOW  takes  over  the  graphics  subwindow  created  by 
GDBX_TOOL.  GDBX3HOW  is  responsible  for  displaying  data  structures  in  this  subwindow  and 
for  sending  mouse  input  from  this  window  to  GDBX. 

To  present  data  structures  on  the  screen,  GDBiLSHOW  first  initializes  a  set  of  purects 
-pixel  rectangles,  bit  patterns  held  in  internal  memory).  These  pixrects  are  written  according 
to  commands  received  from  GDBX.  When  a  data  structure  has  been  completely  wntten  to  a 
pixrect.  the  contents  of  the  pixrect  are  written  to  the  visible  screen  at  a  single  instant. 

Mouse  input  from  the  graphics  window  consists  of  a  button  type  (left,  middle,  or  right) 
and  a  set  of  xy  coordinates  or  menu  selection.  Mouse  input  is  sent  to  GDBX,  which  processes  it 
and  sends  back  commands  to  appropriately  update  the  screen. 

SJl.  Integration  with  DBXTOOL 

GDBX  was  designed  to  be  integrated  into  the  DBXTOOL  product  of  Sun  Microsystems. 
DBXTOOL  IS  a  multiple  subwindow  tool  which  runs  DBX  inside  one  subwindow.  The  subwindows 
present  the  following  information:  a  status  subwindow  names  the  source  file  displayed;  a  text 
subwindow  presents  the  source  file  context  of  the  present  stopping  point;  a  panel  shows  DBX 
commands;  a  tty  subwindow  runs  DBX;  and  a  text  subwindow  displays  values  of  variables. 

The  graphics  subwindow  of  GDBXJTOOL  and  GDBX_SHOW  replace  the  last  text  subwindow. 
The  following  aspects  of  GDBX  were  influenced  by  the  decision  to  integrate  GDBX  into 
DBXTOOL. 

.  It  was  decided  to  make  GDBXJHOW  operate  in  a  separate  graphics  window  rather  than 
attempt  to  use  the  fifth  subwindow  of  DBXTOOL.  The  sizes  of  DBXTOOL’s  four  other 
Bubwindows  severely  constrain  the  size  attainable  by  the  fifth  subwindow.  This  constraint  is 
due  to  subwindows  inside  a  SunWindows  tool  being  tiled,  rather  than  overlapped,  and 
because  each  subwindow  in  DBXTOOL  has  an  absolute  and  practical  minimum  size.  Rather 
than  restrict  users  to  a  small  tiled  window  area,  an  overlapping  window  was  implemented  by 
creating  an  independent  tool  (GDBXJTOOL)  and  having  GDBX_SHOW  take  over  the  graphics 

subwindow  within  this  tool 
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.  Since  GDM  .U1  be  fork«i  by  DBXTOOL  end  .ill  opemt.  within  the  tty  eniulatcr  of  the  fourt 
snbwindc,  GDBX  was  deaignad  t«  .amain  a  normal  ri..ll  command.  An  alternative  w»ld 
have  been  to  fork  GDBX  from  GDBX_TOOL.  .herenpon  GDBX  itself  could  take  over  the  grapto 
eubwindow  ofGDBXTOOL,  However,  thm  would  have  mean,  that  GDBX  could  only  be  run  from 
inside  a  grophics  tool,  making  it  less  general  and  making  it  impossible  to  uri^ie  wrth 
DBXTOOL.  The  process  hierarchy  described  in  this  paper  was  necessiuted  by  the  desire  to 

integrate  GDBX  into  DBXTOCML. 

Tbe  following  sections  describe  in  more  detail,  by  process  and  chronology,  the  algorithms 
that  present  data  structures  graphically. 

8  Box  Construction  Algorithm 

■  When  a  command  U,  display  a  variable’s  value  la  data  structure)  is  given,  GDBX 
constructs  a  representation  of  the  value  that  is  a  linked  ho.  struct^. 
processing  takes  place  upon  this  bo.  structure.  Each  bo.  is  an  object  ^ 

LsicaUy  presented  on  the  screen  to  portray  part  of  the  daU  structure.  Each  bo.  hold^  a 
value,  memorv  address,  name,  sire  in  pixels,  and  an  xj  position  on  the  screen,  ^^a^ 
With  the  bo.  are  user^ehnahle  characteristics  that  affect  the  coasrrucoo  ^ 
representation  or  its  subse,uent  presenroimn  on  the  screen.  The  commands  SHOW, 
*juI*YJEOINXRRAY31ZE.  and  SGTPRESSUNSUPPBESS  «rt  a  bo.  struttures  corrsnucrmn 
characteristics.  whUe  the  commands  OPENCtX.SE  and  ACEOSS«.WN’  affect  a  box’s  preseamnoa. 
The  bo.  structure  is  linked  together  as  foUows:  A  nested  data  structure  is  represented  by 
a  bo.  With  links  to  chad  boxes,  A  bo.  that  has  no  parent  and  that  appears  as  the  outerroost 
bo.  When  drsplaved  will  be  referred  to  as  a  <op-leoeI  box,  A  record  structure  .m  C  or  Pa^l  m 
composed  of  a  top-level  bo.  with  a  pomter  to  a  linked  list  of  child  boxes  each  representing  a 
field  of  the  record.  An  array  is  also  represented  in  this  way.  with  each  child  representing  an 

array  element. 

A  bo.  representing  a  pointer  has  a  link  to  the  bo.  representing  the  data  structure  it 
points  to.  Boxes  that  are  pointed  to  have  links  to  each  bo.  which  pomts  to  them. 

The  algorithm  that  creates  the  bo.  structure  is  a  revision  of  the  DBX  print  routine. 
Where  the  original  DBX  pnnts  a  value  to  the  terminal,  the  GDBX  routine  creates  a  1».  into 
which  the  value  is  printed  las  a  strmg).  The  memory  address  of  thm  value  m  calculated  and 
UKOCiated  with  the  box.  The  bo.  is  then  linked  to  those  boxes  that  define  its  context. 

There  are  several  interesting  additional  modifications  to  the  DBX  print  algorithm  that 
were  necessary  in  GDBX; 

.  in  the  original  DBX.  pointers  are  pnnted  a,  addresses.  In  GDBX  boxes  repre«nting  the 
structure  at  this  address  are  recursively  constructed.  The  values  beginning  at  this  point  m 
the  program’s  address  space  must  be  made  available  to  GDBX  These  values  tdau  stmctur^ 
are  pushed  onto  the  GDBX  stack,  evaluated,  and  then  boxes  for  them  are  cnnstructed 
recursively.  "Hiese  boxes  are  then  linked  into  the  existing  box  structure. 


44 


Sine  structure  poinusi  to  arc  ev.lusted  in  CDBX,  ruther  than  just  their  addesse  ^ing 
printed,  the  possibility  of  inhnite  recue, on  is  uitroduced,  A  hash  table  of  uidex^  by 

Lmon-  address,  is  maintained  to  pevent  such  reueton.  This  box  table  also  ensures  th«  a 
box  that  is  pointed  to  by  eveel  other  boxe  .ill  itself  appear  on  the  scren  only  one,  w. 

manv  arrows  pointing  to  it. 

A  su’btle  exeption  to  the  above  solution  occue  with  teerd-typ.  data 
structues,  the  fiet  f^ld  of  the  record  has  the  same  location  in  memoo-  as  the  wj- 
reconi.  A  special  provision  is  made  to  recognise  this  ese  as  being  non-recursive.  In  effect, 
there  are  two  different  boxes  that  share  the  same  memor>-  address. 

.  Although  boxes  could  hold  only  the  values  to  be  presented  on  the  screen,  ODBX  adds  the  ^ 
of  the  variable  represented  to  the  box  as  well.  This  additional  information  “ 
such  as  SBOW.TOSHOW,  DOWN.ACROSS,  to  be  applied  genetically  to  ty^es.  I”  ' 

:  ^  of  a  variable  lint,  char,  a  typeief  of  a  structure,  etc,  can  be  displayed  with  the  top.,evel 
box  on  the  screen.  Type  informatron  could  also  be  used  to  influence  ho.  a  data  structure  m 

displayed. 

8  4  User  Controlled  Modifications  to  Box  Construction 

There  are  several  commands  available  to  the  user  that  modify  the  oonstruenon  of  the  box 

Structure  described  above. 

8.4.1.  SHOWAUNSHOW 

These  commands  allow  the  user  to  specify  that  a  certain  fleld  of  a  record 
he  included  inexcluded  hum  box  construction.  When  the  boxes  representmg  ^  ^ 
record  are  being  constructed,  the  .hour  field  of  the  variables  type  m  con^lted.  If  the 
anshou ,  the  corresponding  box  is  not  constructed  and  not  linked  to  the  other  fields  boxes 

8.4.2.  ARRAY-BEGIN  AJtRAY-SIZE 

The  user  mav  set  the  element  number  from  which  array  construction  begms.  or  may  limit 
the  number  of  elements  for  which  boxes  are  coimtructed.  To  implement  thm,  the  b^^ 
element  and  sire  limit  assoaated  with  the  array  variable  are  consulted  within  the  loop  that 

constructs  the  boxes  representing  the  array  elements. 

8.4.3.  SUPPRESSi  UNSUPPRESS 

If  the  user  requests  that  0-valued  elements  of  an  array  be  suppressed,  boxes  representing 
elemenu  whose  value  is  0  or  (nU)  are  unlinked  from  the  chain  of  boxes  representing  the  array, 

8.4.4.  PTR-DEPTH 

The  user  may  set  the  depth  to  which  he  would  like  pointers  for  a 
constructed  Depth  is  a  count  of  the  numher  of  pointer  levels  emanating  ftom  the  top 
™.  To  implement  the  depth  Umit,  a  count  of  remrraions  due  to  following  a  pomter 
opposed  to  a  nesting,  is  matnuined.  Reorraion  is  terminated  when  this  count  is  above  the 
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depth  limit  set  for  this  variable  type. 

8J5.  Positiomng  Algorithm 

After  the  linlc«i  boxes  repr«.nting  .  d.u  .tructure  have  been  created,  a  search  U  ni^e 
for  a  place  to  pre^nt  each  top-level  box.  First,  the  sire  of  the  top-level  box  ,s  determmed.  The 
size  of  each  internal  box  is  calculated  recurstvely  and  sumtaed  to  give  the  stze  of  the  wp-level 
box.  A  position  on  the  vu^ual  screen  for  this  top-level  box  is  then  found  that  also  defines  e 

positions  of  all  the  internal  boxes. 

The  procedure  that  inds  a  position  for  a  box  is  an  efficient  one  that  formats  linked  dau 
structures  dynamically  and  pnxluces  reasonable  layouts.  It  does  not  attempt  to  calculate 
specialized  or  refined  layouts.  The  procedure  is  given  the  size  of  a  box.  and  it  rett^s  an  y 
position.  This  routme  is  not  deeply  embedded  in  the  GDBX  code  and  may  therefore  be  replaced 
by  a  program  that  specializes  in  more  accomplished  layouts. 

The  user  mav  command  a  data  structure  of  a  given  type  to  be  presented  either  ACEOSS  or 
nowN  the  screen.'  Presenting  a  date  structure  ACEOSS  the  screen  means  that  “ 

structures  wtll  point  from  left  to  right  and  large  date  structure  will  grow  horizontally.  Data 
structures  presented  DOWN  will  grow  vertically. 

n..  ACEOSS  toWN  commands  are  one  example  of  how  a  user  might  define  the  way  in 
which  he  would  like  to  format  pafticular  data  structures  on  the  screen^  A 
lavout  algorithm  could  incorporate  other  layout  vanations,  such  as  a  binary  tree  form  , 
rjkt  t  format,  etc  When  the  layout  options  are  thu.  extended,  the  OOEX  command 

interface  should  also  be  generalized. 

A  twcvdimensional  array  is  maintained  of  the  parts  of 
occupied  A  search  is  made  for  the  first  space  into  which  the  top-level  box  will  fit.  The  search 
for  an  open  space  on  the  screen  procewls  as  defined  by  the  direction  of  .aceo^ 

Of  the  data  structure's  t>T>e.  The  size  of  the  rows  and  columns  is  determmed  dynamical . 

size  of  the  data  structures  already  on  the  screen.  search  algorithm  hret  attempts  to  find 

an  open  place  on  the  visible  portion  of  the  virtual  screen. 

The  position  of  DEPLAYed  variables  is  maintained  acmes  execution  steps, 
these  structures  at  the  same  position  allows  apparently  instantaneous  update  the  da 
struoure-s  values,  and  miables  changed  values  to  be  emphasmed  (see  BUNKmg  below .. 
new  position  of  a  DEPLAYed  data  structure  that  the  user  has  moved  is  also  mamtamed. 

The  position  of  PEDCred  data  structures  is  not  mainteind  .(mss  execution  step.  Any 
number  of^riables  may  be  PEthTed  in  any  order:  Thus,  to  present  PE^Ted  “  “ 

orderly  fashion,  date  structures  that  were  PEIOTwi  are  clear«i  fmm  tte  screen  ato 
execution  step.  The  position  of  a  PEINTed  variable  is  recalculated  for  each  PEINT  requ 


8.6.  Box  Di^Uy 

A  box  is  displayed  by  sending  GDBTL^HOW  the  coordinates  of  the  four  corners  that  de  ne 


46 


the  box,  the  box’s  name,  and  the  value  to  be  printed  inside.  A  box  is  erased  by  displaying  the 
box  again  with  an  XOR  raster  operation. 

Top-level  boxes  are  placed  on  a  display-list  which  is  searched  when  a  selection  is  made.  A 
box  is  displayed  with  one  of  three  presentation  types;  PRINT,  DISPLAY,  or  ERASE.  The 
presenUtion  type  of  the  box  is  consulted  to  determine  whether  a  box  has  already  been 
presented  or  erased,  thus  terminating  recursion.  ERASEd  boxes  are  removed  from  the  display- 
list  immediately  and  PRINTed  boxes  are  removed  after  an  execution  step 

8.7.  Screen  Presentation 

GDBX_SHOW  receives  messages  from  GDBX  that  indicate  the  coordinates  and  values  of  the 
box  to  present.  The  primitive  graphics  operations  of  printing  vectors  and  stnngs  are  made  to  a 
pixel  rectangle  (pixrect'i  in  memory. 

There  are  four  pixrects  that  GDBX_SHOW  manages.  Two  pixrects  are  for  DISPLAYed  boxes. 
The  pixrect  into  which  DISPLAYed  boxes  are  written  changes  with  each  execution  step,  and  the 
previous  pixrect’s  values  are  preserved.  Changes  occurring  in  a  DISPLAYed  data  structure  are 
then  easily  made  apparent  by  comparing  these  two  pixrect  representations  through  raster 

operations  (see  BLINTCing  below). 

Another  pixrect  is  used  for  PRINTed  data  structures,  which  are  not  re-displayed  at  each 
step.  This  pixrect  is  cleared  on  each  execution  step. 

Just  before  presenting  the  pixrects  to  the  screen,  the  current  DISPLAY  pixrect  and  PRINT 
pixrect  are  written  to  a  scratch  pixrect  which  is  then  written  to  the  screen.  This  use  of  a 
scratch  pixrect  avoids  the  undesirable  flicker  which  occurs  if  two  separate  pixrects  are  written 
to  the  screen  in  succession,  and  makes  the  screen  appear  to  be  instanuneously  updated. 

The  size  of  the  pixrects  maintained  by  GDBX_SHOW  is  larger  than  the  area  of  the  graphics 
subwnndow  on  the  physical  screen.  Only  a  portion  of  the  entire  pixrect  is  actually  wntten  to 
the  screen,  thus  affording  a  'virtual  window’  capability.  The  portion  of  the  pixrect  actually- 
displayed  on  the  screen  is  changed  by  clicking  the  mouse  in  the  vertical  or  horizontal  scroll 

bar. 


8.8.  Mouse  Operations 
8.8.1.  Selection 

A  top-level  box,  a  field  within  a  record  structure,  or  an  array  element,  is  selected  by 
pointing  to  the  field  or  element  and  clicking  it  with  the  left  mouse  button.  The  x,y  coordinates 
of  the  mouse  position  are  sent  to  GDBX.  GDBX  searches  through  the  boxes  on  the  display-list 
and  determines,  by  comparing  coordinates,  which  field  or  element  was  pointed  to. 

Once  the  selected  box  is  determined,  it  is  highlighted  on  the  screen  by  XORing  a  box  of 
background  color  over  the  selected  box.  The  highlighting  is  removed  before  the  selected  box  is 
ERASED  or  when  the  left  button  is  clicked  outside  of  any  box. 
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Structure  Movement 

GDBX  allows  a  user  to  move  data  structures  to  improve  the  screen  display,  or  to  Present  a 
data  structure  as  he  conceives  of  it.  Structure  movement  is  implemented  by  first  identifying 
the  top-level  box  that  the  mouse  is  pointing  to.  TTiis  identification  is  done  as  in 
box’s  dimensions  are  then  sent  to  GDBX^HOW  which  continuously  presents  an  ^  « 

box  as  it  is  drugged  along,  following  the  mouse.  When  the  middle  button  is  released  the  to,> 
level  box  (and  all  its  internal  boxes,  is  erased,  along  with  the  arrows  into  it  and  out  from  it. 
The  new  coordinates  for  the  top-level  box.  are  placed  into  the  box  and  the  box  is  re-presen  . 

Arrows  out  of  the  moved  box  are  corrertly  re-displayed  automatically,  connecting  to  boxes 
already  present  on  the  screen.  Pointers  into  the  moved  box  are  updated  by  re-displaying  each 
of  the  boxes  that  contain  pointers  to  the  moved  box. 

Arrow  Movement 

eating  an  am,w  or  -noving  an  ar™»  to  point  to  a  differant  box  ebangea  not  only 
aorean  tapraaantation  of  tha  data  atmetun*  but  alao  tba  actual  value  (an  addrasai  of  tba 
pointer  variable. 

The  implauiantation  of  arrow  movauiant  is  aimilar  to  that  of  atmetuia  Movamant 
daacribad  abova.  ftlan  tha  middla  button  i«  dapraasad  tba  type  of  tba  currant  aalacn^  .a 
ebaakad  U  tba  aalaction  is  a  pointer  variabla.  thia  fact  it  sen.  «  GDBiLkHOW,  along  wttbrta 
oooniinatas  from  which  amiw  should  begin.  Wi.la  tha  middle  button  tamains  dapij^^ 
ODBXJHOW  continually  presents  sn  arrow  ftom  tha  current  aaJacnon  u.  tba  position  of 

mouse. 

Whan  tha  middla  button  is  raleasad.  tha  mouse  coordmatas  are  sent  to  GDBX  which 
identifies  tba  box  w  which  tba  mouse  is  pointing.  If  tba  box  is  s  raconi  stnictu^,  the  ^r  m 
asked  to  select  a  field  within  thia  tdructura.  m.  operation  for  which  tha  standard  selection 
mechanism  is  used.  Tha  memory  location  of  tha  box  to  which  tha  arrow  now  ^mts  m  wntKn 
to  the  pointer  variable  in  tha  address  space  of  the  program  being  debugged.  Ustly, 
representation  of  the  pointer  on  the  screen  is  updated. 

8.fi.4.  Fonts 

A  variety  of  sixes  of  Roman  and  Bold  fonu  are  available.  Requests  for  a  font  change  are 
sen.  u,  GDBX.  which  compensa«s  for  changes  in  height  and  width  whan  calculating  the  pure! 
dimensions  of  .  box.  The  font  in  which  «x.  U  presented  is  sent  m  GDBX^HOW  by  GDBX  as  one 
of  the  parameters  of  the  text  print  command. 


8J.5.  Blinking 

A  DBPIAYod  dau  structure  is  presented  after  the  completion  of  each  execution  step. 
Within  a  complex  data  sUmeture,  it  may  be  dliScult  to  spot  changes  that  ocmined  as  the  result 
of  this  execution  step  (which  may  consist  of  many  inatmctionsi.  By  uamg  two  piicecta,  one  or 
the  previously  DEPUrVed  values  mid  one  for  the  currently  DEPlAVed  values,  changes  m  value 
can  be  made  to  blink,  thus  rendering  them  readily  apparent. 


48 


Ai>  AND  FASUr  operation  of  the  two  ptxrecu  together  giveo  those  values  that  .ere 
unchanged  by  the  execution  step.  Repeated  XOR  ra.«r  operations  bet^  the  current  valu« 
L  the  «ult  of  the  AND  operation  »ahes  the  new  values  hlinh.  Through  vartous  raster 

operations,  different  types  of  blinking  can  be  obtained. 

8J.  Multiple  Language  Support 

CDBX  .as  onginslly  .ritten  and  debugged  using  only  the  C-lan^age  facilities  of  DBX 
The  language^ependent  routines  h.  DBX  are  eclated  m  a  single  die  for 
supported.  Addition  of  graphic  debugging  for  Pascal  programs  .as  readily  accomplished. 

9.  Performance 

GDBX  does  a  tonsiderable  amount  of  .orlt  in  addition  to  the  dxed  overhead  of  DBX:  ta 
dau  structures  are  built,  information  is  sent  over  .  pipe,  and  displays  are  creaW  on  the 
■  neen  These  additions  are  substantial  and  there  .as  concern  that  performance  could  be  poor. 

,n  fact  the  implementation  of  ODBX  displays  data  structures  .ith  an  acceptable,  even 
surprising  rapidity.  Simple  values  and  small  structures  are  sho.n  almost  instantan^usly. 
The  presentation  of  larger  records  or  linked  structures  have  a  noticeable  lag  time  of  ,mrha^  a 
second  or  t.o.  Yet  thu  U  Uttle  more  time  than  is  required  to  present  s  struaure  on  a  normal 
and  far  less  time  than  it  .ould  Uke  for  the  user  to  print  out  the  structures  pointml 

to  manually. 

The  elapsed  time  and  the  CPC  time  consumed  by  various  display  operations  .as  mea^r^ 
using  the  DNDt  system  call  hme.  A  scnpt  of  commands  placed  in  a  .dbxinh  file  .as  ^  m 
take  the  measurements.  GDBX  and  DBX  .ere  each  run  on  the  same  script  of 
tL.  For  scalar  values  GDBX  ran  approximately  30..  slcer  than  DBX.  GDBX  required  from 

2-10  times  as  long  to  present  structured  data. 

Submitting  commands  automatically  from  a  script  produced  results  for  ^ 

could  be  compared  easily.  Ho.ever,  this  technique  does  not  accurately  refiect  actual  comm 
submissim.  to  a  debugger  .hen  it  is  being  used  interactively,  l^en  a  user  “ 

digest  the  information  displayed  and  to  consider  bis  next  command,  the  additional  nme  tha 
GD^  requires  to  ralculate  and  display  a  data  structure  .ill  be  far  less  evident  than  it  is  in 

these  performance  measurements. 

By  far  the  largest  additional  overhead  incurrad  by  GDBX  is  that  of  .siting  display 
information  over  the  pipe  to  GDBX^HOW.  For  the  display  of  large  mruaures  — 

approximately  of  the  CPU  time.  Intelligent  encoding  of  display  information  could  reduce 

this  appreciably. 

A  description  and  analysis  of  the  types  of  display  operations  measured  are  given  belo.: 

1  Startup/Bun:  This  script  began  the  debugger,  ran  the  program 

quit  .ithout  doing  any  printing  or  graphic  prtoessing.  Compared  to  DB^  the 

required  to  start  up  GDBX.  due  to  forking  GDBXJrOOL,  GDBXJHOW,  and  initialing  the  ntdo" 

rr^len,  .a.  calculated.  This  additional  time  .as  factored  out  the  follovnng 
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■measurements,  whose  intention  is  to  determine  the  time  required  for  displaying  objects  once 
processing  has  begun. 

2  Integer,.  Character.,  String.  :  These  imripts  DEPhaVed  the  value  of  variables  of  <me  of 

these  scalar  types.  The  results  show  that  there  U  an  ins.gnihcant  addifonal  J 

GDBX  CPU  time  is  increased  by  only  10-15%  and  elapsed  time  by  approrimately  30%s 
resulu  imply  that  the  additional  overhead  of  box  construction,  the  placement  algorithm,  and 
pipe  communication  is  acceptably  low  for  these  fundamenUl  types. 

The  presentation  of  these  simple  types  is  the  only  type  of  display  operations  that  <an  be 
directly  compared  between  GDBX  and  DBX.  In  the  remaining  operatkins.  GDBX  acwally  dmplays 
more  information  about  the  data  structures,  or  display,  it  in  a  more  meaning  way^th«. 
does  DBX  Thus,  any  large  performance  degradation  is  mitigated  hy  the  value  added  by  GDBX. 

3  Linked  Structure.-.  ThU  script  DiSPLaved  a  variable  that  is  a  poin«r  to  a  record  structure. 
The  number  of  structures  DiSPUtved  by  GDBX  grew  hum  one,  when  the  pointer  value  was  nd, 
to  a  maximum  of  hve  record  structures  of  three  fields  apiece.  The  corresponding 

of  the  varuble-s  value  by  DBX  always  consisted  of  a  single  address.  The  ti^i^umed  for  the 
display  of  the  linked  structures  by  GDBX  was  approximately  twice  that  required  y  DBX. 

4  Record  Strucmre.:  TTits  script  DEPLAY^i  several  complex,  nested  record  structures.  In 
this  case  the  same  amount  of  information  was  displayed  by  GDBX  and  DBX  but  in  qui  a 
different  'format.  The  time  required  by  GDBX  was  about  triple  that  by  DBX  The  SHOWiurEHOW 
commands  may  be  used  to  trim  the  amount  of  information  displayed  to  achieve  be 

performance. 

5  Array.:  The  script  Integer  Army  DEPlAYed  a  lO-element  integer  array,  and  the  ^pt 
Poiorer  Armv  DEPlAYwi  a  lo^lemen.  «ray  of  pointer  to  record  structures.  In  the  GDBX 
implementatmn,  arrays  are  cast  into  a  box  structure  similar  to  records.  This  imposes  overhead 
on  an  array  that  DBX  does  not,  but  aUows  operations  such  as  OPEN, CLOSE  to  operate  on  arrays 

as  well  as  records. 

In  Potnur  Army.  GDBX  DtSPLAYed  the  structures  that  are  pointed  to  by  each  of  the  arra.v 
elements,  whereas  DBX  printed  only  the  structure’s  address.  This  display  of  additiona 
information  accounu  for  the  large  increase  in  time  required  for  this  script. 

The  final  script,  Ettded  Army,  DBPLAYed  the  same  lO-element  pointer  after  setting 
abkaybee  and  PRCCT^aE  to  5,  replacing  the  default  values  of  10,  The  CPU  time  was  cut  m 
half.  ThU  reduction  came  primarily  from  fewer  writes  due  to  a  smaller  PBINTjaE.  The  use  o 
commands  to  control  presentation  is  effective  in  improving  GDBX  performance. 

Below  are  tables  of  elapsed  time  and  CPU  statistics  for  the  various  types  of  display 
operations. 
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taiapseo  lune 

!*ac! 

Trv* 

Dix  Avg 

ooax  Avg 

Ncrmaliaad 

%  Inaaaae 

OD>X  Avg 

Startup  Ruo 

7.0 

16.5 

(9.5) 

- 

Character* 

13  3 

26.8 

17.3 

30.1% 

Istegeri 

13,3 

27.0 

17.5 

31.6% 

Striag* 

14.0 

28.0 

18.5 

32.1% 

Linkad  Structure 

11.3 

33.0 

23.5 

108  0% 

Record* 

10.3 

43.5 

34 

230.1% 

Integer  Array 

«.5 

37.3 

27.8 

327.7% 

Pointer  Array 

6.0 

78.5 

69.0 

1050.0% 

Ebded  Array 

6.0 
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39.5 

558.3% 

r - Xaer  +  System  iune  ae^ 

h - 

Type 

DBX  Avg 

CDBX  Avg 

Normaliaad 

%  Ingeiit 

ODBX  Avg 

StartupRuo 

1.38 

2.4 

(1.02) 

- 

Integers 

7.0 

&S3 

7.81 

11.6% 

Stnngs 

7.03 

9.1 

8.08 

14.9% 

1 

Character* 

6.85 

&95 

7.83 

15.8% 

Linked  Struct* 

5.15 

1L25 

10.23 

98  6% 

Records 

A66 

16.1 

lAOe 

200.9% 

Integer  Array 

3.5 

U56 

1Z53 

258.0% 

Pointer  Array 

3.38 

34.26 

33.23 

883.1% 

Ebded  Array 

3.38 

20.13 

19.11 

465  4% 

.  J 

10.  Future  Work 

ODBX  mcc^ei  in  presenting  data  atniOurea  graphically  and  in 
Uilorable  «.vimn»ent^  Following  are  son.e  ideas  about  bow  GDBX  can  be  further  enhanced 

and  extended. 

.  A  more  intelUgent  layout  mechanism  tor  linked  structures  can  be  added.  The 

commands  are  a  beginning  in  showing  bow  a  data  stnrcture.  l-y-'  ‘ 

particular  user  or  program.  Ultimately,  a  layout  algorithm  similar  to  ‘“P  • 

CRAB  IDavia  85).  whiri  atatically  formats  directed  graphs,  can  be  mcorporat«i  mm  GDB^ 

Rfi  Iflvout  cslcul&tions  incrc8.96  in 
Performance  would  become  a  concern,  however,  as  layoui  ca 
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complexity.  . 

The  fecUitiee  established  hy  ODBX  for  displaying  dau  structures  g^phitnUy  « ^ 

,  to  other  oh^  that  DUX  currently  presents  textually.  For  «tample,  the 

Treltl:  : te  ^rlch  or  of  a  structure-s  dednition  could  he  enhanced  hy  usutg 

graphic  displays. 

Further  worh  on  displaying  two.di=.ensional  arrays  in  rna^  format  or  allowing  entue 

sections  of  an  array  to  he  selected.  OPENed,  or  CU«Ed  would  be  useful. 

The  graphic  presentation  ahiUties  of  GDBX  tan  be  used  for  applications  other  ^ 
Thug^g  Pr^F--  Ulustruting  algorithms  that  manipulate  data  structures,  as 

J^tor  algorithm  animation  (Brown  851.  could  be  compcsed  usmg  command  scnpts 

placed  in  the  .dbxinU  initialization  files. 


11.  Conclusion 

US  V,  /licnlflVB  of  data  structures  can  be  accomplished  in  a 
CDBX  has  shown  that  ^  U.,  gun  Workstation  window 

user<ontrolled  environment.  is  inCuence  on  the  atademic 

manager,  a  machine  and  environment  that  wiU  exen 

research  community  in  the  future. 

gdbx  was  used,  in  later  stages,  u.  dehug  itself.  H  proved  to  he  valuable  “  ^ 

refererul  task,  aiding  in  the  understanding  of  implex  interna,  data  structures.  GbBX 

also  been  well  received  by  the  user  community  at  UC  Berkeley. 

rwmi-onn  fjver  &  pcriod  of  approximately  five  months. 
GDBX  was  implemented  by  one  pe  nmrtiral  The  value 

Similar  extensions  to  other  debuggers  in  similar  env^nments  would  be  practical,  -me 

derived  by  a  large  user  community  may  make  it  well  worth  the  effort. 

The  major  strengths  of  the  GDBX  projeo  stem  from  it  being  mtegrated  fully 

j  j  V.  r  rnRX  uses  the  standard  debugger  command  interface  to 
known  and  widely  used  debugg  ^  debugging  environment  suited  to  a  particular 

perform  and  mouse  mte.rt.ce  of  SuaWindom.  m  afford  the 

Z  ItXer  the  presentation  of  dam  structures.  successMly  creating  a  more  powerfri,  mid 

effective  debugger. 
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